By Simon Bisson , Columnist, InfoWorld |
Teams has always been on track to be an important part of Microsoft’s productivity platform, but the COVID-19 pandemic pushed it to the top of Redmond’s agenda. Its importance became clear as Microsoft and much of its customer base first shifted away from the office to suddenly work from home, and now is adapting to a more planned approach that’s become hybrid home/office work.
Although much of the focus on Teams has been on its conferencing and collaboration features, its key differentiation from the competition builds on Microsoft’s heritage as a platform company. Right from launch, it was as much a place to build applications as to communicate and collaborate, providing much of the scaffolding and plumbing needed to deliver collaborative, near-real-time applications, as well as acting as another endpoint for line-of-business systems as part of a low-code workflow that hosts the many small tasks that are part and parcel of modern work.
Once you think of it as another platform, it’s not surprising to see Teams get its own track at Microsoft’s Build conference. This year’s event was no different, with several major announcements, including the general availability of a new JavaScript SDK and some major API releases. Perhaps the most interesting, however, was a new set of tools that merge Teams’ own collaboration and conferencing features with Microsoft’s Fluid Framework real-time application development platform.
The result is the Live Share SDK, a way of building collaborative applications that mix meetings with applications that can share state across many different users and devices. We’ve already seen what this approach offers with Visual Studio’s Live Share collaborative coding. Different editors on different platforms can share an editing space, extending pair programming beyond the office.
Teams’ Live Share SDK lets you use Microsoft’s Fluid Framework to relay state between instances in a many-to-many mesh. You can then wrap your code and meetings in a Fluid container, adding collaborative features with minimal code. This way you can use Teams’ tools with your own, for example, sharing code and wireframes in a hybrid meeting review, allowing those in a conference room to annotate on a large screen and people at home to use their own screens. Interactions are in near real time and shared between all users, with Teams controlling the voice and video parts of the meeting. Like many of Microsoft’s recent tools, it’s open source and can be found on GitHub.
Much of the Live Share SDK will be familiar if you’ve been experimenting with the Fluid Framework. Live Share is a set of JavaScript packages and installs via npm or Yarn, with dependencies on both the Teams JavaScript and Fluid Framework packages. If these aren’t installed, installing the SDK will install them. If you already have them, you will need to be sure you have the right versions to avoid problems. Currently, you need both the 2.0.0-experimental.0 version of the Teams JavaScript package and 0.59.0 of Fluid Framework.
There are other limitations at this stage of the preview. Probably the biggest is that Live Share is only available for scheduled meetings; you can’t drop into it in an ad hoc fashion in other types of meetings. All the participants need to be on the invitation; before they get access to a Live Share application, they must accept the meeting invite and add it to their calendars. Hopefully, this is only a preview issue, as the ability to use Visual Studio Live Share for spontaneous collaborations is one of its strengths, and it’s easy to see how a similar approach might help turn a call into a shared workspace.
A Teams Live Share app is like any other Teams application. As it’s not yet part of the Teams developer tools, you’ll need to manually add additional permissions in the app manifest in order to use the new features, starting with scope and context for your application’s host URL with support for group chat with a meeting panel and stage. You then need to add delegated permissions for the Live Share session and the app’s meeting stage. As the platform matures it should become part of the Teams SDK, with support for automatically generated manifests.
You can now start to add Live Share features to your code. Applications need to join a meeting, so each instance of the app will start with the meeting in each user’s Teams session. Code will need to initialize the Teams SDK and then create a Fluid Framework container to handle synchronization between clients, setting up the distributed data structures needed to synchronize content. Fluid Framework has many different data structures, so choose the ones necessary for your application.
The most likely is a SharedMap, which is a basic key-value store for JSON objects. With a SharedMap you’re sending, say, coordinates that have been drawn on a shared image. That can be combined with a SharedString structure for collaborative text editing. These Fluid Framework data structures can persist between sessions and construct post-meeting reports and deliver content for attendees to use offline.
Live Share brings some new features that aren’t in Fluid Framework with what it calls Ephemeral Objects. These are a new form of shared object that’s not stored in a Fluid container but is still accessible in your application. You’d use these to manage user presence or to add presentation tools like a pointer to a session. These are shared using the same real-time Fluid tools, but they don’t exist beyond a meeting unless you explicitly save their contents into a Fluid data structure.
One useful feature is the EphemeralEvent data structure. This can send messages between clients in a meeting, for example, showing if someone has joined or left. Make sure to add code to listen for notifications and run it asynchronously. In fact, much of the code used for both Fluid data structures and Live Share’s ephemeral structures needs to be asynchronous, as your code is sourcing and responding to events that can occur at any time in a meeting.
Although Live Share is perhaps best used to wrap text-based content using Fluid Framework’s collaboration tools, it offers a set of extensions in a separate package that supports media synchronization. This adds a separate ephemeral object to support media controls and state, along with a way of synchronizing playback in an HTML media element. If you’re making a video presentation in a meeting, you can have a Live Share app that lets approved users pause playback to have a discussion or annotate the view.
Live Share can also give us a helpful way to use Teams to broadcast live events, as it has tools to let users pause streams and skip as necessary. There’s an interesting option here if you’re using Live Share to host training: You can allow users to pause to answer a quiz or make comments and only resume playback when all the users resume. Coordination like this is a handy feature as it ensures no one is left behind and that everyone’s views are heard.
Live Share in Visual Studio is a powerful tool, so it’s good to see similar capabilities coming to Teams. However, it’s important to realize that building real-time collaboration tools isn’t easy, and although Teams Live Share simplifies creating and managing shared data structures, you still need to build a set of asynchronous event-handling tools to ensure that changes in shared data are reflected in user experiences. With a tool like Fluid Framework, it’s tempting to go all in, but this can result in complex and unmanageable event-parsing code.
So how should you go about using Teams Live Share? It’s best to start with a simple application: a tool that shares an easy-to-understand data structure, like a Kanban board with a text and audio chat and basic edit features for a hybrid team to run a daily stand-up meeting, managing project backlogs in a way that project managers can quickly see and understand how a project is progressing.
Once you’ve understood how Live Share works with a single shared data structure, you can start to expand your application, adding new features to support new requirements and respond to user requests. The result should be code that works well on meeting room screens and individual desktops, helping bridge the hybrid work divide. It’s the right time for Microsoft to bring out such a tool. Now we need to build the Teams code that takes advantage of these new capabilities.
Author of InfoWorld's Enterprise Microsoft blog, Simon Bisson has worked in academic and telecoms research, been the CTO of a startup, run the technical side of UK Online, and done consultancy and technology strategy.
Copyright © 2022 IDG Communications, Inc.
Copyright © 2022 IDG Communications, Inc.